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Abstract 

A  process  of  sensemaking  in  reverse  engineering  was  elicited 
from  verbal  protocols  of  reverse  engineers  as  they  investigated 
the  assembly  code  of  executable  programs.  Four  participants 
were  observed  during  task  performance  and  verbal  protocols 
were  collected  and  analyzed  from  two  of  the  participants  to 
determine  their  problem-solving  states  and  characterize  likely 
transitions  between  those  states.  From  this  analysis,  a  high- 
level  process  of  sensemaking  is  described  which  represents  hy¬ 
pothesis  generation  and  information- seeking  behaviors  in  re¬ 
verse  engineering  within  a  framework  of  goal-directed  plan¬ 
ning.  Future  work  in  validation  and  application  of  the  process 
is  discussed. 

Keywords:  Sensemaking;  Information  seeking;  Human  com¬ 
puter  interaction;  verbal  protocol  studies. 

Introduction 

Sensemaking  is  a  term  used  to  describe  a  broad  family  of  cog¬ 
nitive  activities  in  which  a  person  comes  to  develop  a  mental 
model  to  represent  the  elements  of  some  situation  of  inter¬ 
est  (Klein,  Phillips,  Rail,  &  Peluso,  2007;  M.  R.  Endsley, 
2000).  Whereas  situation  awareness  refers  to  the  ability  to  at¬ 
tend  to  relevant  information  elements  in  a  task  as  a  situation 
unfolds  (M.  Endsley  &  Rodgers,  1994),  sensemaking  refers 
to  the  process  that  enables  one  to  come  to  an  understanding 
of  the  meaning  and  relevance  of  the  elements  that  make  up 
the  situation  (Klein,  Moon,  &  Hoffman,  2006;  M.  R.  Ends¬ 
ley,  2000).  The  sensemaking  process  has  been  described  as 
an  ongoing  integration  of  knowledge  from  a  mental  model  of 
a  situation,  available  information  about  the  context  of  a  situ¬ 
ation,  and  perceptual  data  from  the  environment  (D.  M.  Rus¬ 
sell,  Stefik,  Pirolli,  &  Card,  1993;  M.  R.  Endsley,  2000). 

Sensemaking  is  described  as  connecting  inferences  and 
observations,  integrating  knowledge  and  conjecture,  find¬ 
ing  explanations  for  ambiguous  data,  diagnosing  ambiguous 
symptoms,  and  identifying  problems  (Klein  et  ah,  2007). 
Sensemaking  also  refers  to  comprehension  of  the  signif¬ 
icance  of  ambiguous  events  and  data  in  the  environment 
(Weick,  1995).  The  many  functions  of  sensemaking  de¬ 
scribe  a  class  of  distinct  cognitive  processes  involving  inter¬ 
actions  between  knowledge,  information,  and  actions  in  an 
environment  which  may  encompass  a  number  of  different  in¬ 
ference  and  learning  behaviors  (Menzies,  1996;  Josephson, 
Chandrasekaran,  Smith,  &  Tanner,  1987).  Sensemaking  has 
been  studied  in  naturalistic  settings  (Klein  et  ah,  2007),  in 
computer-human  interaction  (Pirolli  &  Card,  2005),  in  intel¬ 
ligence  analysis  (Zhang,  Soergel,  Klavans,  &  Oard,  2009), 
and  in  organizations  (Weick,  1995),  but  no  process-level  de¬ 
scription  exists  to  characterize  how  people  make  sense  of  ex¬ 
ecutable  programs. 


As  part  of  a  larger  study  to  understand  and  model  how  peo¬ 
ple  make  sense  of  programs  from  executable  representations, 
we  wanted  to  understand  the  general  interaction  process  that 
is  involved  as  a  person  works  with  a  debugger  to  make  sense 
of  a  program.  While  sensemaking  might  be  a  general  pro¬ 
cess  of  interacting  with  an  environment  to  develop  a  mental 
model,  we  investigated  sensemaking  in  a  particular  applied 
domain  (reverse  engineering  assembly  language)  because  it 
provides  a  restricted  set  of  semantics  to  ground  the  investiga¬ 
tion  without  being  a  “toy”  problem.  This  was  also  essential 
because  understanding  sensemaking  in  that  domain  was  the 
major  focus  of  the  larger  study.  So  while  the  term  ’sensemak- 
ing’  has  been  used  to  mean  many  different  things,  we  were 
interested  in  studying  how  people  connect  information  from 
the  task  environment  with  background  knowledge  in  order 
to  develop  and  modify  a  mental  model,  all  with  a  focus  on 
applying  this  process  to  improve  the  information  processing 
automation  in  software  reverse  engineering  tools. 

To  understand  this  element  of  understanding  executable 
programs,  we  undertook  a  study  to  collect  verbal  protocols 
from  reverse  engineers  while  they  analyzed  programs  from 
assembly  language  representations.  Four  participants  were 
observed  performing  a  challenging  reverse  engineering  task, 
and  verbalizations  from  two  of  the  participants  were  tran¬ 
scribed  and  coded.  From  the  coded  data,  two  participants’ 
state  transitions  were  extracted  to  determine  a  process  involv¬ 
ing  the  state  transitions. 

First,  the  methods  used  in  the  study  are  briefly  described. 
Next,  the  methods  used  in  the  analysis  of  verbal  protocols  is 
presented.  Following  that,  the  process  of  sensemaking  used 
in  the  reverse  engineering  tasks  is  described  in  the  context  of 
complex  problem-solving. 

Method 

The  participants  were  instructed  to  complete  a  problem  called 
Angler  that  was  downloaded  from  the  crackme.de  website 
(Schneider,  T.,  2011)  in  February  20 II1.  Angler  is  a  type  of 
crackme  called  a  keygen  (which  stands  for  key  generation), 
a  type  of  program  that  typically  presents  text  fields  for  the 
user  to  enter  a  name  and  a  serial  number  and  asks  the  partic¬ 
ipant  to  reverse  engineer  the  algorithm  which  processes  the 
user’s  data.  In  keygen  tasks,  people  disassemble  and  reverse 
engineer  the  program  to  discover  a  valid  key  for  a  given  user 

'Shortly  after  obtaining  the  crackme,  the  crackme.de  website 
was  taken  down  from  the  Internet.  The  Angler  program  can 
also  be  obtained  from  the  website  of  the  program's  author  at 
littp://cyclops.  ueuo.  com. 
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name  or  to  write  an  algorithm  that,  when  given  a  user  name, 
produces  a  valid  license  key  that  unlocks  the  functionality  of 
the  program. 

The  Angler  crackme  program  presents  the  participant  with 
a  semi-transparent  visual  window  with  two  entries  for  text. 
It  has  three  buttons,  labeled  “Check”,  “About”,  and  “Exit.” 
When  a  user  submits  a  name  and  serial  number  combination, 
the  application  tests  whether  it  is  a  valid  combination  and  in¬ 
forms  the  user. 

Selection  of  Participants 

The  researcher  solicited  reverse  engineers  to  participate  in  a 
verbal  protocol  study  through  an  e-mail  invitation  to  the  Air 
Force  Institute  of  Technology  and  to  a  cross-organizational 
reverse  engineering  working  group  at  Wright-Patterson  Air 
Force  Base.  The  solicitation  requested  that  participants  have 
knowledge  of  reverse  engineering  and  experience  using  tools 
such  as  OllyDbg,  WinDbg,  Immunity  Debugger,  and  the  IDA 
Interactive  Disassembler.  The  solicitation  produced  four  re¬ 
verse  engineers  from  Wright-Patterson  Air  Force  Base  who 
participated  without  remuneration. 

Data  Collection 

Video  data  of  the  participants’  computer  screen  was  captured 
and  combined  with  audio  recordings  of  the  participants’  ver¬ 
balizations  during  the  task.  The  participant  computer  ran 
a  Windows  XP  operating  system  that  was  hosted  within  a 
VirtualBox  virtual  machine,  and  which  was  preloaded  with 
the  software  tools  and  documentation  identified  from  a  pre¬ 
vious  subject  matter  expert  study  of  the  reverse  engineering 
task.  The  experimenter  viewed  the  participant’s  task  envi¬ 
ronment  remotely  over  a  virtual  network  computing  (VNC) 
connection  using  the  TightVNC  server  and  client  software 
(TightVNC  Software,  2011).  The  experimenter’s  computer 
was  outfitted  with  a  microphone  which  was  wired  into  the 
participant’s  cubicle  to  enable  the  combined  collection  of  au¬ 
dio  and  video  data. 

Each  participant  was  seated  at  a  small  cubicle  in  an  unoc¬ 
cupied,  quiet  room  in  front  of  the  participant  computer  which 
contained  a  mouse,  keyboard,  monitor,  and  the  microphone. 
The  participants  were  instructed  as  to  the  different  reverse 
engineering  tools  and  documentation  available,  and  were  per¬ 
mitted  as  much  time  as  was  needed  to  become  familiar  with 
the  task  environment.  Paper  was  also  available  so  participants 
could  make  notes,  as  recommended  by  Wood  (1997). 

Each  participant  was  given  instructions  on  how  to  ver¬ 
balize  thoughts  during  task  performance  and  was  instructed 
not  to  try  to  explain  the  task  or  thought  processes.  The  ex¬ 
perimenter  stressed  this  point  and  demonstrated  examples 
of  poor,  acceptable,  and  high-quality  concurrent  verbaliza¬ 
tions  with  a  simulated  coffee-making  task  to  help  the  partic¬ 
ipants  understand  how  they  should  verbalize  during  task  per¬ 
formance.  During  the  performance  of  each  task,  the  experi¬ 
menter  was  seated  out  of  the  participant’s  view  in  the  opposite 
cubicle  and  reminded  participants  to  verbalize  when  they  fell 
silent  for  more  than  a  few  seconds  using  simple  prompts  such 


as  “please  remember  to  verbalize  during  the  task”  and  “re¬ 
member  to  talk  aloud”  as  discussed  in  Trickett  and  Trafton 
(2007).  Other  than  those  reminders,  the  experimenter  was 
silent  throughout  the  task,  and  took  notes  about  each  partici¬ 
pants’  goals,  strategies,  concepts,  and  problems  in  the  task. 

Audio  data  of  each  participant’s  concurrent  verbaliza¬ 
tions  and  video  data  of  the  experimenter’s  computer  moni¬ 
tor  (showing  all  actions  on  the  participant’s  computer  moni¬ 
tor)  were  recorded  using  the  CamStudio  software.  After  the 
task,  participants  were  asked  to  recall  what  they  thought  their 
strategies  were,  what  parts  of  the  task  they  thought  were  the 
most  difficult,  what  would  have  made  the  task  easier,  and 
what  they  felt  they  needed  to  pay  attention  to. 

Overview  of  the  Reverse  Engineering  Task 

Participants  were  to  investigate,  modify,  and  re-implement  an 
algorithm  that  an  executable  Windows  program  called  “An- 
gler.exe”  (Cyclops,  201 1)  uses  to  process  a  user-provided  se¬ 
rial  number.  Participants  worked  from  assembly  language 
representations  of  the  program  provided  through  the  IDA  in¬ 
teractive  disassembler  and  the  OllyDbg  debugger  without  ac¬ 
cess  to  source  code  or  debugging  symbols. 

The  code  in  Angler  consists  of  15  major  subroutines,  in¬ 
cluding  the  subroutine  called  WinMain  which  starts  the  win¬ 
dowing  process  and  other  subroutines  to  present  dialog  boxes. 
The  program  runs  within  a  single  thread  of  execution  in  mem¬ 
ory  and  does  not  have  hidden  sections,  encrypted  code,  or 
code  obfuscations.  Angler’s  file  header  contains  pointers  to 
four  program  sections  that  are  mapped  into  memory  at  run 
time:  the  .text,  . rdata,  .data,  and  .rsrc  sections,  which 
are  typical  for  portable  executable  programs  compiled  to  run 
on  Win32-based  operating  systems  (Eilam,  2005). 

Though  there  are  many  strategies  to  approaching  the  chal¬ 
lenge,  successful  completion  required  that  participants  do  the 
following: 

1 .  Read  and  understand  the  goal  of  the  task 

2.  Determine  that  a  system  function  handles  input 

3.  Isolate  the  input  handling  function 

4.  Determine  the  format  for  the  serial  number  input 

5.  “Catch”  the  input  as  the  program  executes 

6.  Craft  data  so  the  program  executes  the  success  message 

7.  Translate  the  function  into  pseudocode 

8.  Write  pseudocode  for  a  key  generator 

An  algorithm  in  the  program  composed  of  27  basic  blocks 
of  assembly  instructions  processes  the  user’s  serial  number. 
The  algorithm  takes  the  first  four  characters  of  the  person’s 
name  and  performs  a  cyclic  redundancy  check  (CRC)  to  pro¬ 
duce  an  even-numbered  value  from  that  character,  finds  four 
pairs  of  prime  factors  that  sum  to  the  even-numbered  values, 
and  assembles  an  eight-value  number  separated  by  dashes 
(Cyclops,  2011).  Through  a  series  of  programmatic  checks, 
the  algorithm  determines  if  the  user’s  serial  number  matches 
the  computed  serial  value.  In  these  checks,  the  last  instruc¬ 
tions  in  each  basic  block  of  code  check  for  a  data  value  from 
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Verbalization  Describes 

Coded  As 

Desired  future  state 

Activities  to  accomplish  goal 
Status  of  an  ongoing  activity 
Noticing  something 
Recognizing  relevance 

More  abstract  statement 

An  assumption 

Question  about  something 

Make  goal  representation 
Plan  approach 

Carry  out  plan 

Sense  information 

Interpret  information 
Update  knowledge 

Create  hypothesis 

Create  hypothesis 

Table  1:  Rules  Used  to  Code  Segments 


the  input  and  then  transfer  the  program’s  execution  based  on 
the  result  of  that  check.  If  the  reverse  engineer  does  not  un¬ 
derstand  the  meanings  of  these  behaviors,  the  program  ap¬ 
pears  to  be  making  a  large  number  of  arbitrary  numerical 
checks  in  a  long  sequence  of  assembly  language  instructions. 

Verbal  Protocol  Analysis 

Participant  B’s  video  and  audio  data  recordings  were  acciden¬ 
tally  destroyed  during  a  problem  with  saving  the  video  file  to 
disk  and  were  not  able  to  be  recovered  or  transcribed.  Ad¬ 
ditionally,  Participant  A  lacked  familiarity  with  the  tools  and 
the  task  and  was  not  able  to  make  sense  of  the  program.  Al¬ 
though  observations  of  all  of  the  participants  provided  valu¬ 
able  context  and  examples,  only  verbal  data  from  Participants 
C  and  D  were  coded  and  analyzed  to  elicit  the  sensemaking 
process. 

Concurrent  verbal  protocols  were  collected  from  Partici¬ 
pants  C  and  D  following  the  method  outlined  in  (Ericsson 
&  Simon,  1980).  We  reviewed  the  video  and  verbal  data 
from  Participants  C  and  D  and  transcribed  it  into  a  spread¬ 
sheet,  broken  into  one  verbal  segment  per  row  as  discussed 
in  Trickett  and  Trafton  (2007).  The  participants’  verbaliza¬ 
tions  were  segmented  during  transcription  in  order  to  take  ad¬ 
vantage  of  other  contextual  clues  from  the  audio  and  video. 
Verbalizations  were  segmented  based  on  whether  they  repre¬ 
sented  a  single  idea,  and  when  a  segment  contained  a  shift 
from  one  idea  to  another,  the  second  idea  was  recorded  in  its 
own  row  as  its  own  new  segment.  Where  significant  verbal 
breaks  occurred,  the  subsequent  verbalizations  were  recorded 
on  a  new  row  as  a  separate  segment. 

After  all  of  the  available  data  was  transcribed,  it  was  coded 
according  to  the  following  taxonomy  of  sensemaking  in  re¬ 
verse  engineering,  established  from  a  previous  literature  re¬ 
view  of  sensemaking  in  reverse  engineering  in  Bryant  et  al. 
Bryant,  Mills,  Peterson,  and  Grimaila  (2012):  Make  the  goal 
representation.  Plan  an  approach.  Carry  out  a  plan.  Sense 
information.  Interpret  information.  Update  knowledge,  and 
Create  a  hypothesis.  This  taxonomy  of  sensemaking  steps 
is  similar  to  the  information-processing  loop  used  in  pro¬ 
gramming  artificial  agents  to  interface  with  an  environment 
(S.  Russell  &  Norvig,  2003),  with  the  addition  of  a  state  to 
generate  goals  and  state  to  generate  hypotheses. 

The  data  from  the  two  participants  were  coded  according  to 


the  coding  rules  in  Table  1 .  To  ensure  that  the  coding  scheme 
was  appropriate  for  the  data,  interrater  reliability  was  com¬ 
puted  between  two  independent  coders.  One  researcher  coded 
all  of  the  data  (592  segments)  and  afterwards  a  second  coder 
independently  coded  29.2  percent  of  the  segments  (173  se¬ 
quential  segments)  without  having  seen  the  original  coder’s 
data,  and  from  a  starting  point  randomly  selected  by  the  sec¬ 
ond  coder.  Cohen’s  Kappa  statistic  (Cohen  et  al.,  1960)  was 
computed  to  measure  interrater  reliability  for  the  29.2  percent 
of  segments  coded  by  both  coders.  Cohen’s  Kappa  measures 
the  agreement  between  coders  on  positive  and  negative  in¬ 
stances  while  taking  into  account  the  likelihood  of  agreement 
based  on  chance.  Cohen’s  Kappa  is  computed  as: 

K=(P0-Pc)/(l-Pc) 

Pa  is  the  proportion  of  agreements  between  the  coders  and 
Pc  is  the  proportion  of  agreement  which  would  be  predicted 
by  chance.  Generally,  a  Cohen’s  Kappa  value  of  0.0  to  0.4 
indicates  zero  to  very  little  agreement,  0.6  to  0.8  indicates 
significant  agreement,  and  0.8  and  above  represents  near  per¬ 
fect  agreement,  though  there  is  disagreement  in  the  literature 
about  specific  ranges  of  values  (Bakeman  &  Gottman,  1997; 
Trickett  &  Trafton,  2007).  After  both  coders  independently 
coded  the  data,  the  interrater  reliability  was  calculated  and 
the  coders  met  to  discuss  disagreements.  If  codes  had  weak 
interrater  reliability  (0.4  or  below),  the  categories  were  re¬ 
moved  or  changed  and  the  data  was  recoded.  The  final  in¬ 
terrater  reliability  for  the  dual-coded  verbalizations  was  0.82, 
which  demonstrates  significant  to  “near  perfect”  agreement 
in  all  categories  (Table  2).  Following  standard  practice,  the 
remainder  of  the  verbalizations  were  coded  by  the  researcher 
(Trickett  &  Trafton,  2007). 

Computing  State  Transitions 

The  state  transitions  from  the  two  participants’  data  were 
computed  to  determine  how  the  reverse  engineers  made  sense 
of  the  programs.  Transitions  between  the  states  indicated 
movement  through  the  problem-solving  process 


State 

Category 

Cohen’s  Kappa 

a 

Make  goal  representation 

0.93 

b 

Plan  approach 

0.82 

c 

Carry  out  plan 

0.78 

d 

Sense  information 

0.72 

e 

Interpret  information 

0.75 

f 

Update  knowledge 

0.81 

g 

Create  hypothesis 

0.92 

Average  agreement 

0.82 

Table  2:  Interrater  Reliability  of  Coding  Scheme  (173  seg¬ 
ments) 

As  described  in  Bakeman  and  Gottman  (1997),  matrices  of 
state  transition  probabilities  were  computed  to  determine  the 
process  used  in  the  task.  For  m  states  Sj  and  5a-,  and  n  seg- 


1388 


ments  i,  the  total  transitions  between  each  state  Sj  and  state 
Sk  are  computed  as: 


Tr(Sj,Sk)  =  Y  C Su  x  %u) :  S  £  (0,1)  (1) 

i=  1 

The  total  transitions  departing  a  state  Sj  are  computed  as: 

m 

Tr(Sj,out)  =  Y  Tr(Sj,Sk)  (2) 

k= l 

The  total  transitions  entering  a  state  Sk  are  computed  as: 

m 

Tr(in,Sk)  =  YTr(Sj,Sk)  (3) 

j=  1 


The  overall  transition  probabilities  for  state  Sj  to  Sk  are 
computed  as: 


P(Tr(Sj,Sk)) 


1  (Tr(Sj,Sk)  Tr(Sj,Sk) 

2  Tr(Sj,out )  Tr(in,Sk) 


(4) 


Using  these  equations  to  compute  the  state  transitions, 
the  state  transition  probabilities  for  the  two  participants  are 
shown  in  Table  3  and  Table  4. 


a 

b 

c 

d 

e 

f 

g 

a 

0.17 

0.24 

0.10 

0.10 

0.15 

0.00 

0.04 

b 

0.14 

0.20 

0.21 

0.21 

0.03 

0.00 

0.12 

c 

0.10 

0.13 

0.05 

0.33 

0.09 

0.10 

0.00 

d 

0.10 

0.08 

0.12 

0.37 

0.37 

0.10 

0.14 

e 

0.00 

0.11 

0.25 

0.22 

0.25 

0.28 

0.18 

f 

0.05 

0.00 

0.00 

0.10 

0.10 

0.21 

0.29 

g 

0.23 

0.15 

0.07 

0.10 

0.17 

0.07 

0.38 

Table  3:  Transition  Probability  Matrix  (Participant  C) 


a 

b 

c 

d 

e 

f 

g 

a 

0.21 

0.26 

0.22 

0.15 

0.14 

0.00 

0.04 

b 

0.18 

0.19 

0.26 

0.18 

0.09 

0.00 

0.11 

c 

0.08 

0.12 

0.07 

0.22 

0.11 

0.10 

0.13 

d 

0.08 

0.21 

0.09 

0.45 

0.28 

0.18 

0.18 

e 

0.18 

0.06 

0.08 

0.22 

0.24 

0.20 

0.03 

f 

0.13 

0.03 

0.07 

0.12 

0.10 

0.31 

0.16 

g 

0.25 

0.07 

0.04 

0.15 

0.03 

0.08 

0.10 

engineers  or  the  broader  sensemaking  process.  Nevertheless, 
previous  studies  have  used  observations  and  verbal  data  from 
small  samples  during  exploratory  research  as  way  to  generate 
hypotheses  which  are  to  be  verified  with  further  investiga¬ 
tion  and  more  participants  (Newell  &  Simon,  1972;  Trickett 
&  Trafton,  2007).  The  verbal  protocols  from  the  two  partic¬ 
ipants  and  the  observed  problem-solving  processes  from  all 
four  participants  are  useful  to  provide  a  framework  for  un¬ 
derstanding  how  reverse  engineers  make  sense  of  executable 
programs. 


Discussion 

Figure  1  shows  a  process  of  how  the  sensemaking  behaviors 
were  used  by  reverse  engineers  attempting  to  solve  the  An¬ 
gler  task.  When  the  participants  were  working  on  problems  in 
the  task,  they  continually  moved  through  a  loop  of  activities, 
which  included  the  establishment  of  a  goal  representation,  a 
plan  to  achieve  the  goal,  carrying  out  the  actions  of  the  plan, 
sensing  information  from  the  task  environment,  interpreting 
the  information,  potentially  updating  knowledge  if  the  infor¬ 
mation  was  relevant,  and  developing  hypotheses  based  on  the 
new  knowledge.  The  sensemaking  loop  in  Figure  1  shows 
this  cycle  as  a  Markov  model  populated  with  the  probabilities 
that  each  state  transition  would  occur. 


(a)  Make  goal 
representation 


Table  4:  Transition  Probability  Matrix  (Participant  D)  Figure  1 :  Sensemaking  Processes  from  the  Reverse  Engineer¬ 

ing  Task 


The  mean  transition  probabilities  were  computed  as 
I/NY4  P(Tr(Sj,Sk))  for  N  participants.  The  mean  transition 
probability  was  /v  =  0.14  and  the  standard  deviation  was  a  = 
0.09.  The  threshold  for  significance  was  set  at  /j  +  a  =  0.23. 
The  significant  transitions  at  the  threshold  P(Tr)  >  0.23  are 
shown  in  Figure  1 . 

Because  only  two  participants’  verbalizations  were  coded, 
inferences  cannot  be  made  about  the  how  the  processes  from 
these  two  samples  apply  to  the  broader  population  of  reverse 


While  progressing  through  this  process,  the  participants 
gathered  information  to  help  them  construct  and  refine  their 
mental  models  of  the  Angler  program.  As  the  participants 
worked  on  the  problem,  they  gained  information  about  com¬ 
ponents  such  as  functions,  the  program’s  execution  paths, 
data  in  the  program,  and  sequences  of  instructions.  They 
were  then  able  to  relate  these  elements  to  items  in  the  task 
environment. 
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Plans,  Goals,  and  Actions 

Once  the  participants  had  verbalized  a  goal,  this  often  was 
immediately  followed  with  the  development  of  a  partially- 
constructed  plan  of  actions  which  would  enable  the  attain¬ 
ment  of  the  goal.  If  the  goal  was  to  gather  information  from 
the  task  environment,  the  plan  involved  actions  which  the  per¬ 
son  could  use  to  help  gather  the  required  information.  Like¬ 
wise  if  the  goal  was  to  configure  the  program  or  the  reverse 
engineering  tools  in  a  particular  way,  then  the  plan  involved 
sequences  of  actions  which  led  the  person  to  be  able  to  change 
elements  in  the  situation. 

In  some  cases,  a  participant’s  goal  did  not  directly  lend  it¬ 
self  to  a  plan,  so  the  person  deliberated  over  different  ideas 
to  construct  and  evaluate  an  approach  that  would  generate  a 
usable  plan.  Sometimes  the  deliberation  was  verbalized,  and 
others  it  was  inferred  by  the  presence  of  long  pauses. 

Participants  appeared  to  determine  the  best  actions  for  their 
situation  by  thinking  through  hypothesized  behaviors  and  in¬ 
ferred  future  states  of  the  program.  When  participants  verbal¬ 
ized  plans,  their  plans  involved  sets  of  actions  in  which  some 
of  the  actions  were  sequenced.  Sometimes  the  participants 
did  not  order  their  actions  into  a  sequence  until  they  were 
already  taking  some  initial  actions  and  detecting  conflicts  in 
how  those  actions  would  affect  the  state  of  the  situation. 

Other  plans  the  participants  expressed  included  search¬ 
ing  information  from  the  reverse  engineering  tool  about  text 
strings,  debugging  the  program  to  see  how  the  program’s 
memory  stack  changes,  labeling  a  function  so  it  can  be  identi¬ 
fied  later,  inserting  a  breakpoint  after  the  initialization  routine 
to  “catch”  the  program,  and  tracing  data  as  it  flows  through  a 
function  during  simulated  program  execution. 

Information  Processing  and  Interpretation 

Participants  processed  information  by  actively  seeking  it  out 
and  by  passively  noticing  information  during  the  performance 
of  some  other  action.  When  participants  passively  sensed  the 
information,  they  executed  the  Angler  program  to  gather  in¬ 
formation  about  its  behaviors  or  looked  through  the  disassem¬ 
bled  code  to  gather  clues  that  might  be  useful. 

When  participants  actively  sought  out  information,  they  set 
a  goal  for  the  information  they  were  interested  in  obtaining, 
made  a  plan  to  acquire  that  information,  and  followed  the  plan 
by  carrying  out  actions  in  the  task  environment.  In  one  exam¬ 
ple,  a  participant  wrote  down  the  addresses  of  system  calls 
and  used  the  search  features  of  the  debugger  to  find  each  of 
the  calls. 

Participants  actively  sought  out  information  about  the  pro¬ 
gram’s  behavior  by  isolating  phenomena.  To  do  this,  partici¬ 
pants  used  the  debugger  to  move  the  program’s  execution  past 
a  system  call  (which  performs  some  action  for  the  program), 
and  then  looked  through  the  current  register  values  and  disas¬ 
sembled  code  in  the  debugger  to  determine  what  had  changed 
in  the  state  of  the  program. 

In  either  active  or  passive  information  processing,  the  par¬ 
ticipants  seemed  to  perform  some  initial  processing  to  deter¬ 


mine  whether  the  information  was  relevant  to  one  of  their 
goals,  and  consequently  ignored  or  attended  to  the  informa¬ 
tion.  If  participants  deemed  the  information  as  relevant,  they 
interpreted  it  to  connect  it  to  concepts  they  already  under¬ 
stood.  If  the  information  element  and  its  connected  concept 
provided  the  person  with  a  new  perspective  or  more  insight 
that  was  relevant  to  one  of  their  goals,  the  person  verbal¬ 
ized  a  phrase  indicating  they  had  updated  their  knowledge. 
These  phrases  were  typically  summarized  or  distilled  state¬ 
ments  that  captured  the  essense  of  how  the  different  concepts 
were  related. 

During  coding  discussions,  the  second  coder  characterized 
this  process  as  when  the  person  “compiled”  their  information 
in  an  analogous  manner  to  how  a  compiler  converts  a  pro¬ 
gram’s  source  code  into  executable  code. 

Mental  Models  and  Hypotheses 

Once  participants  had  added  new  summarized  knowledge  to 
their  mental  model  of  a  program,  they  often  came  up  with  a 
hypothesis  directly  afterward.  Participants  appeared  to  gen¬ 
erate  hypotheses  in  the  task  after  deducing  the  logical  conclu¬ 
sions  of  new  knowledge  they  had  acquired. 

Hypotheses  and  assumptions  were  generated  mainly  af¬ 
ter  participants  sensed  and  interpreted  information  and  up¬ 
dated  their  knowledge  with  the  implications  of  this  informa¬ 
tion.  The  participants’  hypotheses  took  the  form  of  verifiable 
statements  such  as:  “it  looks  like  GetDialogltem  creates  a 
handle  to  some  part  of  the  dialog  that’s  open.”  In  this  case, 
the  participant  started  a  subsequent  loop  through  the  sense¬ 
making  process  with  the  goal  of  verifying  whether  or  not  the 
GetDialogltem  function  creates  such  a  Window  handle. 

The  hypotheses  that  resulted  from  this  process  were  typ¬ 
ically  used  to  generate  a  new  goal,  such  as  to  seek  out  in¬ 
formation  from  the  environment  to  confirm  or  refute  a  fact 
or  to  investigate  another  line  of  investigation  about  how  the 
program  works.  However,  when  participants  did  not  progress 
through  the  process  to  the  development  of  a  hypothesis,  they 
were  not  able  to  generate  information-seeking  goals  and  got 
“stuck”  in  the  task.  In  these  cases,  participants  reverted  to  ex¬ 
ploring  instructions  or  behaviors  of  the  code,  since  they  did 
not  have  specific  hypotheses  about  the  Angler  program  to  in¬ 
vestigate. 

Conclusions 

A  process  of  sensemaking  in  reverse  engineering  was  de¬ 
scribed  and  characterized  through  obervations  and  analysis 
of  verbal  protocols  from  participants  reverse  engineering  pro¬ 
grams  from  assembly  language  representations.  Verbal  pro¬ 
tocols  were  analyzed  to  extract  state  transition  patterns  from 
two  reverse  engineers’  performance,  and  from  that  data  a  pro¬ 
cess  of  sensemaking  was  elicited  and  the  steps  of  that  pro¬ 
cess  were  described  in  a  theory  of  how  people  make  sense 
of  executable  programs.  Participants  were  observed  forming 
goals,  creating  plans  to  achieve  their  goals,  and  carrying  out 
plans.  Participants  also  sensed  information  from  the  task  en¬ 
vironment,  interpreted  the  information,  updated  their  mental 
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model  with  the  information,  and  generated  hypotheses  from 
that  integration  which  led  to  new  goals. 

This  research  represents  a  necessary  step  toward  increasing 
the  autonomy  of  reverse  engineering  tools,  and  can  be  used  to 
determine  a  general  theory  of  sensemaking  that  can  improve 
the  ways  in  which  people  interact  with  other  complex  sys¬ 
tems.  The  work  is  limited  in  that  it  only  involved  observations 
of  four  participants  and  collection  of  verbal  protocols  from 
two  participants,  and  its  generality  is  potentially  limited  by 
the  nature  of  the  task;  nevertheless  the  results  provide  insight 
which  can  be  used  to  develop  a  more  general  computational 
theory  of  sensemaking  through  future  empirical  study. 

Future  work  is  needed  to  determine  the  generality  of  how 
people  work  through  this  process  in  similar  information¬ 
processing  tasks.  Future  research  is  also  needed  in  deter¬ 
mining  how  these  processes  can  be  realized  as  models  within 
established  computational  cognitive  architectures.  Finally, 
work  is  needed  in  employing  these  findings  to  improve  hu¬ 
mans’  interactions  with  complex  systems  such  as  reverse  en¬ 
gineering  tools. 
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